1. Field of the Invention
The present invention is related to data communications. In particular, the present invention is related to hierarchical grouping of multicast traffic in an internetwork for improved, scalable, secure multicast data communications.
2. Description of the Related Art
Multicast data communications, or simply, multicast, is characterized by the transmission of data packets or frames from a source node to a plurality of destination nodes via an internetwork. If the plurality of destination nodes is sufficiently large, multicasting a data transmission significantly reduces the source node resources required to send the data transmission to each of the destination nodes, the network bandwidth consumed by the data transmission, and the latency associated with receiving the data transmission at each of the destination nodes. As pointed out in Mittra, S., Iolus: A Framework for Scalable Secure Multicasting, In Proceedings of ACM SIGCOMM '97, it is essential that multicast (i.e., group) data communications over the Internet are secure. However, given the primarily unicast and point-to-point nature of data communications over the Internet, much of the recent work on network security is inapplicable to multicast data traffic. Indeed, in a draft document by Canetti, B., et al., A Taxonomy of Multicast Security Issues, May, 1998, a number of security issues relating to multicast traffic is discussed. What is needed is an internet security protocol designed with multicast (i.e., group) data traffic in mind.
A proposed Internet Protocol (IP) security scheme set forth in a March, 1998 Internet Engineering Task Force (IETF) Network Working Group draft of “Security Architecture for the Internet Protocol”, and recent work on multicast security, including “Scalable Multicast Key Distribution” (Request For Comments (RFC) 1949), “Group Key Management Protocol (GKMP) Architecture” (RFC 2094), “Group Key Management Protocol (GKMP) Specification (RFC 2093), and “A Secure, Scalable Multicast Key Management Protocol” (MKMP), indicate that multicast group data communication should use a single security association, i.e., a single key, for all multicast data traffic destined to the multicast group. However, these security schemes and security key distribution schemes are not scalable as the scope and size of the multicast group and/or network size increases. Furthermore, the prior art security schemes do not interoperate with proposed or existing IP multicast protocols such as set forth in the Multicast Extensions to OSPF specification (MOSPF—RFC 1584), the Distance Vector Multicast Routing Protocol (DVMRP) specification, and the Protocol Independent Multicast Sparse Mode (PIM) protocol specification. What is needed is a secure multicast scheme in which security associations may be partitioned and used only as needed in one or more portions of multicast group networks.
In some multicast data security schemes, such as Iolus, security associations for the same multicast group differ from one point to another point in the network, or from a higher level service providers to lower level service providers. For example, a securities trading service may encrypt data, e.g., stock trade and/or quote data, using a top level multicast group key, and multicast the data to several brokers. The brokers may, in turn, decrypt the multicast data using the top level multicast group key, again encrypt the data using new group keys, and then multicast the data to the ultimate destination nodes in the network.
The prior art multicast security mechanism described in Iolus divides multicast security groups into subgroups and allows security associations to differ from subgroup to subgroup. However, one disadvantage of this scheme is the latency incurred by decrypting and re-encrypting each packet of data as it is received and transmitted from subgroup to subgroup between a source node and the ultimate multicast destination nodes. Also, using local group or subgroups may result in improper execution of certain multicast data security applications that only identify and recognize a single multicast security group. What is needed, therefore, is a multicast traffic security scheme that avoids the problems described above in connection with the Iolus scheme.